⚠️ No Changeset found

Latest commit: 09b6c5b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Hey @zhangtony239 — I only removed the interface section in #2701 because my PR makes hiding the greeting a default, and would have left it an empty section. I have no issue with it coming back if there's a reason for it to exist.

That said, I think there are two conflicting ideologies here:

• One is that flexibility (customization) is the ultimate good, and everyone's needs should be catered to.
• The other is the ease of use is the ultimate good, and that sensible defaults are the most important thing, with customizability coming at a detriment to ease-of-use.

I tend to think more on the latter side. The interface is already quite complex and can be difficult for new users to navigate, so adding more features and customization options could make it even more frustrating for them. This is also a fast moving codebase and features/structures are changing all the time, so each feature and additional piece of UI represents capital to be managed. It needs testing, support, and be accounted for when other changes happen. This potentially lowers the iteration speed: The bigger your house is, the more work you need to do to maintain it.

With specific respect to customizable stylesheets:

• What happens if a css selector changes, or a piece of UI moves? We can't control the custom stylesheets, so do we just roll with the possibility that we break user setups over and over, week after week?
• What happens if a novice user does something like * {display:none} and blanks out the interface altogether?
  It's okay for these things to happen if we deem them okay, accept the potential instability, or build in escape hatches, but we should ask these questions and go in knowing the risks!

So I understand and support the desire for personalization, but I hope you also understand why my priority is on reducing the learning curve and refining the core interface to work well for the majority of users first, and why those things can sometimes be at odds with customizability.

My three suggestions would be that:

• Prefer sensible defaults over customization first. For something like a greeting message, it doesn't need to be configurable — we probably all agree the greeting message can just be smarter about when it appears. Onboarding UI can usually be moved to the welcome screen and never shown again after it it shown once. This benefits everyone!
• Each instance of proposed customizability be viewed within the lens of tech debt. Consider what happens if the feature changes, if other features change around it, or how it might need to be managed in the future.
• Consider risks. With something like a customizable stylesheet, we either need to catch * {display:none} risks or build escape hatches around them when things go wrong with novice users.

Hope this make sense. Let me know your thoughts.

Hey @sachasayan , thank you for the thoughtful reply — I really appreciate the way you laid out the design principles behind your decision. And to clarify: I don’t mean to hold any grudges over #2701. In fact, @cte already kindly offered to help with restoring the Interface section if needed, so it’s not a big deal at this point. My earlier message may have sounded more emotional than I intended — sorry if it came across that way.

That said, I would still like to clarify a few points regarding the intention behind this PR.

The CSS override feature is clearly marked as a Power user feature – use with caution! and is wrapped in a <fieldset> with proper warnings. It’s not meant for the average user, and it’s specifically not a replacement for more thoughtful, built-in personalization settings. Instead, it's a fallback — a way to make the project more flexible without cluttering the UI or increasing maintenance burden for the team.

In fact, I actually agree with most of what you said about tech debt and user experience. Sensible defaults are crucial, and trying to satisfy every niche through settings can spiral out of control quickly.

But my main concern — and maybe it came through a bit emotionally before — is about discouraging future contributions around personalization. I don’t mean to say you are doing that intentionally, but I do worry about this mindset becoming codified in the project culture. Something like "we already have a CSS override, no need to make the interface more flexible" could easily creep into future PR if we atmosphere this too much, and I think that would be a shame.

And actually, quite the opposite of ideological conflict — this PR was born because I, after going through my last two PRs and seeing the challenges, chose to stand closer to your side: to look for a compromise between personalization and maintainability. That’s why this solution tries to isolate complexity while leaving the core interface untouched. It's not a demand for change — just an invitation to let others explore what’s possible.

I totally understand that you, or others, may not have the bandwidth to push for more personalization right now. That's totally fine. I just hope the door stays open for those who might. We can be pragmatic and still welcoming.

Really appreciate the discussion — looking forward to hearing your thoughts.

Building alignment mean we butt heads and step on toes sometimes @zhangtony239, never apologize for being passionate about making OSS better. ✌️😇

But my main concern — and maybe it came through a bit emotionally before — is about discouraging future contributions around personalization. I don’t mean to say you are doing that intentionally, but I do worry about this mindset becoming codified in the project culture. Something like "we already have a CSS override, no need to make the interface more flexible" could easily creep into future PR if we atmosphere this too much, and I think that would be a shame.

It's an interesting idea, and an interesting concern. I share this thought with you, and I'll add on that another concern that if there's a CSS override, people won't feel motivated to contribute their improvements back to the core codebase. In other words, there's the "I already have a CSS override, no need to throw up a PR" dynamic to consider.

Question for you, @zhangtony239 while you were thinking about this: Have you considered a limited number of (supported and curated) preset theme packs, and if so, why was that direction rejected?

Hey @sachasayan,

Thanks again for the thoughtful reply! But as you pointed out before, the potential issues with CSS overrides (like breaking with updates) are exactly why I don't think this will lead to fewer PRs or reduce contributions to the core.

Actually, the reason I still chose to submit this PR after thinking about it is because I believe that by offering this layer of flexibility, it can help expand Roo's appeal and increase its user base. The more people can personalize and experiment with the project, the more they will engage with it. This could actually lead to a more vibrant and active community, and the issue tracker could become a more exciting place with fresh ideas and contributions, even if personalization isn't our top priority right now.

I completely agree with you that we might not have the bandwidth to focus on personalization for the time being. But this approach provides a way for people to explore possibilities and keep the interest of those niche groups (like power users or enthusiasts) engaged. These users can still share ideas and open issues that may inspire us later, or maybe even spark new insights that we hadn't considered.

Ultimately, I see this as a pragmatic way to keep the project inclusive and flexible, without overcomplicating the core features or creating unnecessary maintenance work. So I don’t think we’ll miss out on valuable contributions or inspiration by adding this level of customization — instead, it keeps the door open for innovation while maintaining the stability of the core.

In short, although in the long term, a thematic system should indeed be designed, and the interface settings should be properly improved to be user-friendly, I believe this approach is meaningful in the short term.

Looking forward to hearing your thoughts on this approach!

(Hey @zhangtony239, I can tell when you're using ChatGPT for your responses. 😇)

It sounds like we both agree themes are the better long-term path, and there's tech debt risk in pursuing a css injection layer. Let's close this for now and we can revisit shortly when the UI is more stable. I think I've got a decent mid-way solution coming up which should be an acceptable compromise, but if my solution doesn't work for you, ping me and we'll talk about it.